6.9 Erweiterung der Klassenhierarchie »CircleApplication« 

Wir wollen uns nun noch einmal dem von uns immer weiter entwickelten Beispielprojekt CircleApplication zuwenden, den Entwurf um zwei weitere Klassen, nämlich um Rectangle und GraphicRectangle, ergänzen und uns dabei die in diesem Kapitel gewonnenen Kenntnisse zunutze machen. Die Klasse Rectangle soll ein Rechteck beschreiben und die Klasse GraphicRectangle eine Operation bereitstellen, um ein Rectangle-Objekt in einer grafikfähigen Komponente darzustellen – analog zur Klasse GraphicCircle.

Ebenso wie ein Circle-Objekt soll auch ein Rectangle-Objekt seine Lage beschreiben. Dazu wird ein Punkt vom Typ Point mit seinen x- und y-Koordinaten definiert. Um bei der üblichen Konvention grafischer Benutzeroberflächen zu bleiben, soll es sich dabei um den oberen linken Punkt des Rechtecks handeln. Die Größe eines Rechtecks wird durch seine Breite und Länge definiert. Außerdem sind Methoden vorzusehen, um Umfang und Fläche zu berechnen und zwei Rectangle-Objekte zu vergleichen.

Die Klassendefinition Rectangle könnte dann wie folgt aussehen:

Und nun auch noch der Code der Klasse GraphicRectangle:

Es ist deutlich zu erkennen, dass sich die Klassen Rectangle und Circle ähneln, ebenso die beiden Klassen GraphicCircle und GraphicRectangle. Dies spricht dafür, allen vier Klassen eine Basisklasse vorzuschalten, welche die gemeinsamen Merkmale eines Kreises und eines Rechtecks beschreibt: Wir werden diese Klasse im Folgenden GeometricObject nennen.

Ein weiteres Argument für diese Lösung ist die sich daraus ergebende Gleichnamigkeit der gemeinsamen Merkmale: Es werden dann die Methoden, die ihren Fähigkeiten nach Gleiches leisten, unabhängig vom Typ des zugrunde liegenden Objekts in gleicher Weise aufgerufen. Einerseits lässt sich dadurch die abstrahierte Artverwandtschaft der beiden geometrischen Objekte Kreis und Rechteck verdeutlichen, andererseits wird die Benutzung der Klassen wesentlich vereinfacht, da nicht zwei unterschiedliche Methodennamen dasselbe Leistungsmerkmal beschreiben.

Hier klicken, um das Bild zu Vergrößern

Abbildung 6.6     Die Klassenhierarchie des Projekts »CircleApplication«

Nach diesen ersten Überlegungen soll nun die Klasse GeometricObject implementiert werden.

6.9.1 Die Klasse »GeometricObject« 

Vergleichen wir jetzt Schritt für Schritt die einzelnen Klassenmitglieder von Circle und Rectangle, um daraus ein einheitliches Konzept für den Entwurf des Oberbegriffs GeometricObject zu formulieren.

Instanzvariablen und Eigenschaftsmethoden

Ein Circle-Objekt wird nach dem augenblicklichen Stand durch seinen Radius und ein Point-Objekt namens center beschrieben, dessen Koordinaten über die Eigenschaftsmethoden XKoordinate und YKoordinate festgelegt werden.

Auch zur Positionsbeschreibung eines Rechtecks dient ein Point-Objekt. Allerdings kann nach der augenblicklichen Implementierung die Positionierung nur über die direkte Übergabe eines Point-Objekts an die Eigenschaft Position erfolgen.

Obwohl sich beide Klassendefinitionen hinsichtlich der Positionsdatenübergabe unterscheiden, bietet es sich uns an, jeden der beiden Typen sowohl mit einer Eigenschaft vom Typ Point als auch mit Eigenschaften, die das Festlegen der Koordinaten in X- und in Y-Richtung ermöglichen, auszustatten. Mit dieser ergänzenden Maßnahme erhöhen wir für jeden Typ sogar noch die Flexibilität, ohne dabei Einbußen in Kauf nehmen zu müssen. Wir können also alle mit der Positionierung im Zusammenhang stehenden Klassenelemente in die Basisklasse GeometricObject auslagern.

Der Radius eines Circle-Objekts sowie die Länge und die Breite eines Rectangle-Objekts sind objektspezifische Daten. Diese Instanzvariablen lassen wir in den ursprünglichen Klassendefinitionen.

Beide Klassendefinitionen definieren außerdem das private Feld counterReduced, mit dem der Objektzähler beim Zerstören des Objekts mit Dispose und dem Destruktor gesteuert wird. Unter Änderung des Zugriffsmodifizierers in Protected ist auch dieses Datenmember ein erstklassiger Kandidat für die neu geschaffene Basisklasse.

Konstruktoren und Destruktoren

Da sich Konstruktoren und Destruktoren nicht an die abgeleiteten Klassen vererben, bleiben die Erstellungs- und Zerstörungsroutinen in Circle und Rectangle unverändert. Ein eigener Konstruktor in GeometricObject ist nicht notwendig, weder der parameterlose noch ein parametrisierter.

Die Instanzmethoden

Ein Vergleich hinsichtlich der Instanzmethoden beider Klassen führt zu der Erkenntnis, dass beide Klassen eine gleichnamige überladene Methode Bigger veröffentlichen, die zwei Objekte miteinander vergleicht und die Referenz auf das größere der verglichenen Objekte als Resultat des Methodenaufrufs an den Benutzer zurückgibt. Aus logischer Sicht erbringen diese Methoden sowohl in Circle als auch in Rectangle dieselbe Leistung, unterscheiden sich nur im Typ des Parameters bzw. des Rückgabewerts: Die Bigger-Methode in der Circle-Klasse nimmt die Referenz auf ein Kreisobjekt entgegen, die Klasse Rectangle die Referenz auf ein Rectangle-Objekt.

Wir können uns den Umstand zunutze machen, dass sowohl die Circle- als auch die Rectangle-Klasse aus derselben Basisklasse abgeleitet werden, und müssen dazu nur den Typ des Parameters und der Rückgabe entsprechend anpassen:

Weil Circle und Rectangle von GeometricObject abgeleitet werden, gilt, dass sowohl ein Circle-Objekt als auch Rectangle-Objekt gleichzeitig auch ein Objekt vom Typ GeometricObject ist. Beide Methoden werden unter Übergabe einer spezifischen Objektreferenz aufgerufen, welche die Laufzeitumgebung implizit konvertiert. Als Nebeneffekt beschert uns diese Verallgemeinerung, dass wir nun in der Lage sind, die Flächen von zwei verschiedenen Typen zu vergleichen, denn nun kann die Bigger-Methode auf eine Circle-Referenz aufgerufen und als Argument die Referenz auf ein Rectangle-Objekt übergeben werden.

In der Bigger-Methode wird GetFlaeche aufgerufen, die natürlich weiterhin typgebunden ist, da die Fläche auf die typspezifischen Daten Radius bzw. Laenge und Breite zugreift. Es liegt aber nahe, GetFlaeche als abstrakte Methode festzulegen, die von den ableitenden Klassen Circle und Rectangle überschrieben werden muss. Polymorph wird dann der Zugriff auf die richtige Implementierung sichergestellt. Mit derselben Argumentation kann auch GetUmfang als abstrakte Methode in GeometricObject definiert werden.

MoveXY ist im Vergleich zu den beiden vorgenannten Methoden typunabhängig und kann daher vollständig in GeometricObject implementiert werden.

Die Klassenmethoden

Die Argumentation, die uns dazu brachte, die Instanzmethode Bigger in der Basisklasse zu codieren, kann auch bei den Klassenmethoden Bigger und IsBigger geführt werden. Wir müssen jeweils nur den Typ des Parameters und bei der Methode Bigger auch den des Rückgabewerts ändern, um die Klassenmethoden in der Klasse GeometricObject bereitzustellen.

Das Ereignis »MeasureError«

Wir wollen nun auch das Ereignis MearureError in GeometricObject implementieren und es allen abgeleiteten Klassen bereitstellen. Das ist jedoch nicht ganz so einfach und verlangt eine genauere Analyse, wie Sie noch sehen werden.

Rufen wir uns zuerst die Implementierung des Ereignisses in der Klasse Circle in Erinnerung:

Ausgelöst wird das Ereignis MeasureError in der Eigenschaftsmethode Radius mit:

Der Übergabeparameter des Delegaten vom Typ Circle versetzt den Benutzer der Klasse in die Lage, bei einer unzulässigen Zuweisung an Radius im Ereignishandler auf die Objektreferenz den Radius neu einzugeben, beispielsweise:

Ähnlich ist der Sachverhalt in Rectangle. Diese Klasse stellt auch ein Ereignis MeasureError bereit, dieses ist jedoch vom Typ MeasureErrorRectangleEventHandler.

Das Ereignis wird, ähnlich wie in der Klasse Circle, ausgelöst, wenn einer der beiden Seitenlängen ein negativer Wert zugewiesen wird.

MeasureError soll in der Klasse GeometricObject als Ereignis dienen, wenn entweder einem Circle- oder einem Rectangle-Objekt ein unzulässiger Wert übergeben wird. Damit wird sofort die erste Konsequenz klar: Da wir weiterhin davon ausgehen, dass bei Ereignisauslösung in einem Circle-Objekt dieses die Referenz auf sich selbst an den Ereignishandler übergeben will, müssen wir den Typ in der Parameterliste des Delegaten entsprechend anpassen. Ein Rectangle-Objekt, dessen Ereignis bisher noch nicht die Referenz auf sich selbst dem Ereignishandler mitteilte, kann davon nur profitieren.

Wir lassen zunächst alle anderen Aspekte hinsichtlich der Implementierung in den Klassen außen vor und stellen weitere Überlegungen an. Wird MeasureError bei dieser Definition in einem Circle-Objekt ausgelöst, kann im Ereignishandler der Radius nach vorheriger Konvertierung der Referenz sender neu zugewiesen werden, z.  B.:

Etwas anders verhält es sich jedoch, wenn entweder die Breite oder die Länge eines Rechtecks nicht den Vorgaben entspricht. Woher soll der Ereignishandler die Information nehmen, welcher Eigenschaft ein unzulässiger, negativer Wert zugewiesen worden ist? Es stehen keinerlei Informationen darüber zur Verfügung, ob es sich um Breite oder Laenge gehandelt hat.

Wir sollten eine Lösung für dieses Problem finden, denn dasselbe Ereignis bei der Auslösung durch ein Circle-Objekt anders zu behandeln als bei der Auslösung durch ein Rectangle-Objekt wäre eine schlechte Alternative. Die Lösung muss für beide in Frage kommenden Typen zu einer gleichwertigen Behandlung führen.

Der Ansatz, der uns zum Ziel führt, geht über die Definition eines weiteren Parameters, der im Ereignishandler die Referenz auf den Wert liefert, der fälschlicherweise zugewiesen wurde.

Der Ereignishandler in einer Clientklasse, der die Korrektur durch den Anwender zur Laufzeit zulässt, könnte im einfachsten Fall wie folgt codiert werden:

Sollte es sich als notwendig erweisen, kann die Referenz sender daraufhin untersucht werden, ob der Auslöser ein Circle- oder ein Rectangle-Objekt war. Aber auch ohne diese Unterscheidung wird der Referenzparameter den neuen Wert immer richtig an die Ereignisquelle weiterleiten.

Wir haben das endgültige Ziel nahezu erreicht, müssen aber jetzt noch dem Umstand Beachtung schenken, dass Ereignisse in der Klasse ausgelöst werden, in der sie definiert sind. Damit das in einer Basisklasse definierte Ereignis auch für den Code in einer abgeleiteten Klasse zugänglich ist, muss die Basisklasse GeometricObject nicht nur das Ereignis MeasureError, sondern auch eine Methode bereitstellen, die in der Art eines Adapters die Verbindung zwischen einer Sub- und der Basisklasse sicherstellt, wenn die abgeleitete Klasse das Ereignis auslöst:

Objekte der abgeleiteten Klassen Circle und Rectangle müssen jetzt die Methode OnMeasureError aufrufen und neben dem Me-Zeiger auch den Wert als Referenz übergeben, der die Ablehnung im Objekt verursacht hat. Behandelt der Client das Ereignis und weist einen neuen Wert zu, wird über OnMeasureError der korrigierte Wert an das Objekt der abgeleiteten Klasse weitergeleitet. Hier kann nun eine erneute Überprüfung durch einen weiteren Aufruf der entsprechenden Ereignismethode erfolgen. Beispielhaft sei das an der Eigenschaft Radius in der Klasse Circle gezeigt: